feat(sub2api): support opt-in check-in for compatible deployments - #1229

🏁 Script executed:

#!/bin/bash
# Description: Inspect extractDataFromApiResponseBody and isApiResponseBody behavior.
set -euo pipefail
rg -n -C 8 'function extractDataFromApiResponseBody|function isApiResponseBody' src/services/apiTransport/request.ts

Repository: qixing-jk/all-api-hub

Length of output: 159

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== candidate files =="
git ls-files | rg '(^|/)src/(services/apiService/sub2api/index\.ts|services/apiTransport/request\.ts|constants/siteType\.ts)' || true

echo
echo "== fetchSub2ApiRawBody and imports/context =="
sed -n '1200,1280p' src/services/apiService/sub2api/index.ts

echo
echo "== fetchApi definitions/usages =="
rg -n -C 5 'const fetchApi|function fetchApi|export const fetchApi|export function fetchApi|extractDataFromApiResponseBody|isApiResponseBody|new.*fetchApi<unknown>|fetchApi<unknown>' src/services src/constants 2>/dev/null || true

Repository: qixing-jk/all-api-hub

Length of output: 17444

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== sub2api check-in routes and parsing =="
rg -n -C 5 'SUB2API_CHECKIN_ROUTES|parseSub2ApiCheckinPayload|isSub2ApiAlreadyCheckedError|fetchSub2ApiRawBody|/api/v1/(check-in|redeem/checkin)' src/services/apiService/sub2api src/services/checkin

echo
echo "== checkin payload implementation files =="
fd -a 'checkin|Checkin' src/services/checkin src/services/apiService/sub2api | sed 's#^\./##'

echo
echo "== request helper type and response implementation =="
sed -n '320,580p' src/services/apiTransport/request.ts
sed -n '1,90p' src/services/apiTransport/response.ts

echo
echo "== fetchApi implementation =="
sed -n '756,788p' src/services/apiTransport/request.ts

Repository: qixing-jk/all-api-hub

Length of output: 23145

🌐 Web query:

sub2api check-in /api/v1/check-in response success message data

💡 Result:

Based on the technical documentation for the sub2api platform, there is no /api/v1/check-in endpoint [1][2]. The sub2api system explicitly does not support a check-in feature for user accounts [3]. In related integration contexts, it has been noted that the platform does not expose a compatible check-in endpoint, which often results in the disabling of such features in external clients or UI wrappers [3]. The sub2api User API endpoints, which are prefixed with /api/v1/, are primarily focused on profile management, API key handling, and usage tracking [1][2]. Standard successful responses in the sub2api system follow a consistent format, typically handled by internal response helpers (e.g., response.Success) that return JSON data containing the requested resource or status information [4]. If you are encountering a response message for a check-in request, it is likely not part of the official sub2api core API contract [2].

Citations:

• 1: https://deepwiki.com/Wei-Shaw/sub2api/8.2-user-api
• 2: https://deepwiki.com/Wei-Shaw/sub2api/8-api-reference
• 3: feat(sub2api): add key management support for sub2api accounts #572
• 4: https://github.com/Wei-Shaw/sub2api/blob/5a8d6c4e/backend/internal/handler/auth_handler.go

🌐 Web query:

"Wei-Shaw" sub2api "checkin" "code" "Already checked"

💡 Result:

In the context of the Wei-Shaw/sub2api project, a check-in code refers to a mechanism for daily user attendance and reward systems [1]. The "Already checked" status indicates that the user or account has successfully completed the daily check-in process for the current day, preventing duplicate check-ins and duplicate rewards [1]. Key aspects of this feature include: Daily Check-in Functionality: The feature allows users to perform a daily check-in through the platform to earn rewards (such as points or account balance) [1]. System Logic: When a user attempts to check in, the system verifies the current check-in status [1]. If the check-in has already been performed for the current date, the system returns a message confirming that the account is "Already checked" (or equivalent, depending on the localization) to prevent abuse [1]. Implementation: This functionality is handled on the backend through specific API endpoints, and the status is tracked in the system's database to maintain state across sessions [1]. Management: Administrators have access to configuration options to define check-in rewards and view check-in status for accounts via the admin dashboard [1]. Additionally, related tools like "all-api-hub" also integrate with these systems to manage and automate such check-in processes for relay accounts [2][3][4]. If you are encountering an "Already checked" message, it simply confirms that the action has already been successfully executed for today [1].

Citations:

• 1: feat: 添加每日签到功能 Wei-Shaw/sub2api#510
• 2: e3bce39
• 3: 28b3f66
• 4: https://skillsllm.com/skill/all-api-hub

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== parseSub2ApiCheckinPayload implementation =="
sed -n '170,260p' src/services/apiService/sub2api/checkin.ts

echo
echo "== known Sub2API response helper names =="
rg -n 'Success|Data|Response|checkin|already check|code in' src/services/apiService/sub2api src/services/checkin || true

echo
echo "== all-api-hub checked-in behavior in issue context (local repo issue mentions) =="
rg -n -i '572|already checked|check-in|checkin' src README.md package.json 2>/dev/null || true

Repository: qixing-jk/all-api-hub

Length of output: 50378

🌐 Web query:

"sub2api" "data": { "reward" | "isCheckedInToday" | "success" | "message"

💡 Result:

The data structure you referenced is associated with the Daily Check-in functionality implemented in the Sub2API platform [1]. This feature allows users to perform a daily check-in to receive rewards, such as balance or points [1]. In the context of Sub2API and related management tools (like All-API-Hub which tracks check-in status for such platforms) [2][3], the structure appears to be a response object from the check-in API endpoint [1][2]. Based on technical implementation details from the Sub2API codebase and integration modules, the response typically includes the following fields [1][2]: - reward: The amount or type of benefit granted (e.g., credit/balance) upon a successful check-in [1]. - isCheckedInToday: A boolean flag indicating whether the user has already completed the check-in for the current day [2]. - success: A boolean indicating whether the API request was successful [2]. - message: A string providing feedback or status information (e.g., "ok", "Already checked in", or error descriptions) [2]. This data is used by the frontend to update the user's check-in status, show the reward received, and provide appropriate notifications [1][2]. Administrative settings in Sub2API allow administrators to define these rewards [1].

Citations:

• 1: feat: 添加每日签到功能 Wei-Shaw/sub2api#510
• 2: 28b3f66
• 3: https://github.com/qixing-jk/all-api-hub

🌐 Web query:

Wei-Shaw/sub2api checkin data reward isCheckedInToday

💡 Result:

In the context of Wei-Shaw/sub2api, isCheckedInToday is a boolean status flag associated with the daily check-in feature [1]. This feature, introduced to the sub2api platform, allows users to perform daily check-ins to receive rewards such as credits or balance [1]. Key points regarding this field: 1. Origin and Purpose: The daily check-in functionality, including the tracking of check-in status, was implemented to enhance user engagement by providing a mechanism to earn rewards [1]. The backend provides API interfaces to manage these check-ins, while the frontend displays the status and provides a button for users [1]. 2. Reliability and Usage: In external management tools like All API Hub, which integrate with sub2api and other similar platforms, the isCheckedInToday flag is sometimes considered unreliable for determining whether to execute an automated check-in [2]. Instead, these tools often prefer to rely on direct responses from the upstream provider (e.g., an already_checked status) to confirm if a check-in has already been successfully performed [2]. 3. Data Structure: Within the system's configuration and DTO (Data Transfer Object) schemas, isCheckedInToday exists within check-in configuration structures (often nested under siteStatus or customCheckIn) to track whether a user has already checked in for the current day [3][4]. If you are developing or debugging code involving this field, note that external tools have specifically addressed bugs related to the default values of this flag [5] and have implemented logic to preserve this custom check-in data during account re-detection or sync processes [3][6].

Citations:

• 1: feat: 添加每日签到功能 Wei-Shaw/sub2api#510
• 2: https://all-api-hub.qixing1217.top/auto-checkin.html
• 3: 28b3f66
• 4: https://github.com/jlwebs/AllApiDeck/blob/44196dde40ecc708084a22db283414ada6af7abc/tmp_log_utf8.txt
• 5: https://github.com/qixing-jk/all-api-hub/blob/main/docs/docs/changelog.md
• 6: feat(navigation): add bulk external check-in functionality #344

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== exact Sub2API check-in-related fields in local payload/parser =="
rg -n -C 3 'isCheckedInToday|Reward|reward|Already checked|already checked|ALREADY_CHECKED_STATUS_CODE|extractSub2ApiCheckinMessage' src/services/apiService/sub2api/checkin.ts

echo
echo "== fetchViaCurrentTabContent implementation =="
rg -n -C 4 'fetchViaCurrentTabContent|parseResponseByType|onlyData:.*true|onlyData: undefined|onlyData' src/services/apiTransport/request.ts | head -n 120

Repository: qixing-jk/all-api-hub

Length of output: 6234

🌐 Web query:

Wei-Shaw sub2api daily check-in Response Success data isCheckedInToday reward

💡 Result:

The daily check-in feature in the Wei-Shaw sub2api platform allows users to earn rewards by performing a daily sign-in [1]. This feature, introduced in early 2026, includes backend API endpoints, service layer logic, and a database schema to handle check-in status and reward distribution [1]. Regarding the specific terms requested: 1. isCheckedInToday: This is a boolean field within the check-in configuration and status data structures [2][3]. It indicates whether a user has already performed their check-in for the current day [2]. Systems often use this field in conjunction with date tracking to prevent duplicate check-ins [4][2]. 2. Response Success data: The API endpoints related to user activities, such as daily usage or check-ins, typically return a structured JSON response [5][6]. A successful response is standardly wrapped in an object containing a code and a data payload [6], where the data field contains the requested information (e.g., check-in success status, reward details, or usage items) [5][4]. 3. Reward: Administrators can configure specific rewards (such as platform balance or credits) that are issued to users upon a successful daily check-in [1]. It is important to note that while isCheckedInToday is a standard field used to track state, some implementations caution that it may not always be the sole source of truth [4]. Developers sometimes prefer to rely on server-side responses from upstream providers (often indicated by flags like already_checked) to verify the actual success of a check-in event [4].

Citations:

• 1: feat: 添加每日签到功能 Wei-Shaw/sub2api#510
• 2: 28b3f66
• 3: 0655288
• 4: https://all-api-hub.qixing1217.top/auto-checkin.html
• 5: Wei-Shaw/sub2api@51f7218
• 6: https://github.com/Wei-Shaw/sub2api/blob/5a8d6c4e/frontend/src/types/index.ts

🌐 Web query:

site:github.com/Wei-Shaw/sub2api checkin controller data isCheckedInToday reward success message

💡 Result:

In the context of the sub2api project, the "daily check-in" feature was implemented to allow users to earn rewards, such as balance or points [1]. While your query specifically asks about isCheckedInToday and its associated "reward success message" within a controller, the current implementation of this system follows patterns found in the project's existing redeem and user service modules [2][3][4]. Based on the architectural implementation of similar features (like the redeem code system), you can expect the following flow for a daily check-in controller: 1. Request Validation: The controller handles the incoming check-in request, likely triggered by a user action in the personal center [1]. 2. Logic Execution: A dedicated service layer (e.g., CheckinService) verifies the check-in status (isCheckedInToday logic) to prevent duplicate rewards within the same day [1]. 3. Reward Issuance: If the user has not checked in, the service issues the configured reward [1]. 4. Success Response: The controller returns a JSON response containing the success status and a message [5][6]. In this codebase, success messages are often handled via frontend toast notifications (e.g., appStore.showSuccess(t('...'))) triggered by the returned API message [5][7]. If you are implementing this, ensure your backend service returns a clear message field in the response body, which the frontend can then interpret and display to the user as a success toast [6][4]. Consistent with other parts of the system, this logic should be wrapped in an idempotent service layer to prevent double-claiming [2][4].

Citations:

• 1: feat: 添加每日签到功能 Wei-Shaw/sub2api#510
• 2: https://github.com/Wei-Shaw/sub2api/blob/5a8d6c4e/backend/internal/service/redeem_service.go
• 3: https://github.com/Wei-Shaw/sub2api/blob/5a8d6c4e/backend/internal/handler/user_handler.go
• 4: https://github.com/Wei-Shaw/sub2api/blob/5a8d6c4e/backend/internal/handler/admin/redeem_handler.go
• 5: https://github.com/Wei-Shaw/sub2api/blob/5a8d6c4e/frontend/src/views/user/RedeemView.vue
• 6: https://github.com/Wei-Shaw/sub2api/blob/5a8d6c4e/frontend/src/api/redeem.ts
• 7: https://github.com/Wei-Shaw/sub2api/blob/5a8d6c4e/frontend/src/views/admin/RedeemView.vue

🏁 Script executed:

#!/bin/bash
# Description: Check whether earlier beforeEach hooks reset mocks in a way
# that could clobber the module-level mockIsSub2ApiCheckinEnabled default.
rg -n 'restoreAllMocks|resetAllMocks|mockIsSub2ApiCheckinEnabled' tests/services/apiService/sub2api/index.test.ts

Repository: qixing-jk/all-api-hub

Length of output: 530

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== file size =="
wc -l tests/services/apiService/sub2api/index.test.ts

echo "== top-level mock setup =="
sed -n '50,85p' tests/services/apiService/sub2api/index.test.ts

echo "== first prior beforeEach with restoreAllMocks =="
sed -n '610,645p' tests/services/apiService/sub2api/index.test.ts

echo "== second prior beforeEach with restoreAllMocks =="
sed -n '1435,1455p' tests/services/apiService/sub2api/index.test.ts

echo "== opt-in describe block =="
sed -n '2728,2754p' tests/services/apiService/sub2api/index.test.ts

echo "== nearby tests around first reset =="
sed -n '645,690p' tests/services/apiService/sub2api/index.test.ts

Repository: qixing-jk/all-api-hub

Length of output: 5412